Standardizing SDM for Model Transformations

Transformations are a key technology in model driven software engineering since they are used to implement refinements for platform independence, restructurings for software migration and weavings for aspect composition. By considering transformations as models, one can develop transformations in the same paradigm as conventional applications. In this paper, we illustrate how Fujaba’s language for graph rewriting has been applied for the CASE tool independent development of model transformations. 1. MODEL TRANSFORMATION IN FUJABA As Sendall and Kozaczynski state [2], model transformation can be seen as the heart and soul of model driven software development. Model transformations therefore deserve to be treated as first class entities in software development. Considering transformations as models [3], recent experiments [4] have shown that Story Driven Modeling (SDM [5]) can be used as a language for the visual development of refactorings (which are a particular kind of “horizontal” model transformations). However, SDM’s implementation in Fujaba suffers from two significant problems. First, the SDM metamodel in Fujaba is non-standard and it is only implicitly present in the source code. As a consequence, only the Fujaba editor is suitable to create and store SDM instances. Second, the Fujaba code generator exclusively generates code conforming to non-standard conventions, meaning it can solely be deployed on the Fujaba repository. 2. A NEW SDM COMPILER BASED ON MDA STANDARDS Both these problems can be overcome by making use of a few MDA standards. More specifically UML, as an alternative for SDM, MOF for standardized (meta)model access and storage, and finally A more elaborated paper on this work has been accepted at the ICGT’04 workshop on Software Evolution through Transformations [1]. JMI as the binding between MOF and the Java programming language. 2.1 UML Profile for Model Transformation The first issue has been tackled by designing a UML profile for SDM, the aim being to resemble the SDM concrete syntax as closely as possible, while keeping the semantics in place. Thus, an attempt was made to associate each SDM construct with a suitable UML counterpart. To handle different variations of the same construct (such as for each activities versus code activities versus normal story activities), UML stereotypes have been used to make the distinction. Mapping the control flow part of SDM proved to be fairly straightforward, because of the presence of activity diagrams in the UML standard. For the Story primitives, the closest match were object (collaboration) diagrams. However, these don’t seem to be available in every CASE tool, and even if they are, they often offer less visual features (such as displaying attribute assignments), than class diagrams. Therefore, the latter were the preferred candidate. The fact that the semantics of UML class diagrams in the context of model transformation differ somewhat from their conventional usage, does not really pose a problem, as people probably know what context they are dealing with. Furthermore, the model transformation semantics are formalized in OCL, although this currently needs to be checked in a separate tool, as CASE tools typically do not allow the addition of meta-constraints yet. As an illustration, Table 1 lists part of the actual mapping of SDM to UML. SDM Construct UML Construct Story Activity ActionState ForEach Activity ActionState with «for each» stereotype Unbound object UmlClass Bound Object UmlClass with «bound» stereotype Table 1: Extract from SDM to UML mapping It should be clear that any UML compliant CASE tool can now be used to create SDM instances. Additionally, since UML complies to the MOF [6] standard, any MOF repository can be employed for storing the models in a standardized way. For example, the NetBeans MetaData Repository (MDR [7]) is an open source Java implementation of MOF (or JMI [8] to be more precise) that is used in several UML and MDA tools [9, 10]. Note that the latter